NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/9849

Internet Message Format | 1996-08-05 | 3.7 KB

Path: rcp6.elan.af.mil!rscernix!danpop
From: [e-mail] (Dan Pop)
Newsgroups: comp.lang.c
Subject: Re: Segmentation Fault ???
Date: 11 Mar 96 12:15:17 GMT
Organization: CERN European Lab for Particle Physics
Message-ID: <danpop.826546517@rscernix>
References: <4hsa7i$[e-mail]> <4huis1$[e-mail]> <[e-mail]> <4hvaq3$[e-mail]>
NNTP-Posting-Host: ues5.cern.ch
X-Newsreader: NN version 6.5.0 #7 (NOV)

In <4hvaq3$[e-mail]> [e-mail] (Toby K Hay) writes:

>Kazimir Kylheku ([e-mail]) wrote:
>
>: It means that you are making errors in your code that the Turbo C environment
>: doesn't catch. The bus error is likely caused by invoking
>: implementation-specific behavior that is in contravention to standard C:
>: converting a pointer to one that has a stricter alignment. On many of the
>: processors used in UNIX workstations, the address of a long word has to be
>: divisible by four. On a 68000 processor, the address of a 16-bit word has to be
>: divisible by two.
>: If you fail to meet these alignment restrictions, the hardware will trigger an
>: exception, and the UNIX kernel will send a SIGBUS signal to your program.
>
>Would lint catch this for me,

Maybe, maybe not.

>or will I have to learn about alignment restrictions to run my program?

You don't have to learn anything about alignment restrictions.  If your
code is correctly written, the alignment restrictions are taken care of
by the compiler (which knows everything about alignment restrictions).

If you convert a pointer to a data with looser alignment restrictions
to a pointer to data with stricter alignment restrictions, you're shooting
yourself in the foot.  Actually, you're shooting youself in the foot with
almost all pointer conversions, the only one which is safe is to signed
or unsigned char pointer (the compiler will perform conversions to and
from void pointers automatically for you, except for some special cases:
functions without prototypes or variable argument lists).

>: A ``segmentation fault'', (SIGSEGV signal), on the other hand, is caused by
>: accessing illegal memory, such as dereferencing a null pointer, reaching past
>: the limits of your malloc heap or stack and so forth.
>
>From three replies I received via E-mail I understand that accessing
>illegal memory is almost certainly caused by using uninitialized pointers
>- something I will check my code for again.

Some compilers can do this checking for you, if you know how to ask them to
(e.g. gcc -O -Wall).  However, "almost certainly" is a bit of exaggeration:
badly initialized pointers (e.g. explicitly or implicitly with NULL),
bad pointer arithmetic and bad free() calls are also frequent causes of
segmentation faults.

>But what determines the
>limits of my malloc heap, stack, and so forth?  Can I request more memory
>for these at the command line when I start the program?

malloc will tell you when it failed to allocate the requested memory block.
You should NEVER use the value returned by malloc before testing it.

If you have a stack overflow problem (not very likely on a Unix box),
the problem is usually in your code, which uses an unjustified amount of
automatic data.  Before declaring an automatic array, ask yourself whether
that array does indeed need to be automatic.  If the answer is "no",
declare it as static.  If the stack overflow was caused by recursion,
then it is very likely that your algorithm is not suitable to a recursive
approach.  If you _really_ have to increase your stack, ask your sysadmin
how to do it (probably using a shell built-in command, a la "limit").

Dan
--
Dan Pop
CERN, CN Division
Email: [e-mail]
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland